Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use standard warnings for internal pytest warnings #3931

Merged
merged 44 commits into from
Sep 5, 2018

Conversation

nicoddemus
Copy link
Member

This PR replaces our usage of the internal warnings system to use standard warnings instead.

Some comments:

Fix #2452
Fix #2908
Fix #3251

…nmanager

It seems this has no effect since `pluggy` was developed as a separate
library.
pytest_logwarning is no longer emitted by the warnings plugin,
only ever emitted from .warn() functions in config and item
Once we can capture warnings during the config stage, we can
then get rid of this function

Related to pytest-dev#2891
Standard warnings already contain the proper location, so we don't need
to also print the node id
@nicoddemus nicoddemus changed the title Internal warnings Use standard warnings for internal pytest warnings Sep 4, 2018
Copy link
Member

@asottile asottile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code looks good -- how does this interact with capwarn?


@staticmethod
def cache_dir_from_config(config):
return paths.resolve_from_str(config.getini("cache_dir"), config.rootdir)

def warn(self, fmt, **args):
self._warn(code="I9", message=fmt.format(**args) if args else fmt)
import warnings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets please make the imports toplevel and introduce a PytestCacheWarning which expresses the warnings of this subsystem

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicoddemus i beleive as a followup we should inline this method and adapt stacklevels, so people see the warnings located in their code

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets please make the imports toplevel and introduce a PytestCacheWarning which expresses the warnings of this subsystem

This is worth discussing a little: should we in general create a new warning class for each plugin, or just using PytestWarning is enough?

My take is that just having a few warning classes is enough, I don't see much reason to have a ton of warning classes unless we have a good use case for that.

I ask because there's only 2 calls to Config.warn:

self.warn("could not create cache path {path}", path=path)
...
self.warn("cache could not write path {path}", path=path)

Is Config.warn something that we meant to be public so others use it? It feels like it was made public without much thought behind it, mostly seems like an accident to me actually.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicoddemus this self.warn can be completely replaced by a warnings.warn

i beleive we can remove it as internal api, if there turns out to be a user, we can bring it back


* ``"config"``: during pytest configuration/initialization stage.
* ``"collect"``: during test collection.
* ``"runtest"``: during test execution.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for better tracking i propose having not just runtest, but also the item phases called setup, call, teardown

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, done!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops just discovered that trying to catch warnings in pytest_runtest_setup, pytest_runtest_call and pytest_runtest_teardown cause problems with recwarn fixture. I don't see a way to fix this properly.

Any suggestions here @RonnyPfannschmidt ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i believe we need to find a way to connect the fixture there - i propose postponing the detail work on that as i believe it will be tricky , require a tracking data-structure and a set of extra support utilities

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I'm reverting this to "runtest" then.

If we implement support for setup, call and teardown in the future, we will have a breaking change in our hands because of runtest...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, can we fake it by just implementing it like runtest, but switching the internal string based on phase?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But warnings are cached by warnings.catch_warnings, so it seems out of our control.

Feel free to try out an idea and pushing to my branch if you have a clear picture on how to implement it. 👍

if item is not None:
for mark in item.iter_markers(name="filterwarnings"):
for arg in mark.args:
warnings._setoption(arg)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw - its a "bug" that we dont use our own setoption here, as it prevents regex usage

@nicoddemus
Copy link
Member Author

nicoddemus commented Sep 4, 2018

Finally all builds have passed. I believe I have addressed all comments, so this is ready for a final review. 👍

Copy link
Member

@RonnyPfannschmidt RonnyPfannschmidt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tremendous and fabulous work, this shaped up nicely over time

@codecov
Copy link

codecov bot commented Sep 5, 2018

Codecov Report

Merging #3931 into features will increase coverage by 0.01%.
The diff coverage is 98.21%.

Impacted file tree graph

@@             Coverage Diff              @@
##           features    #3931      +/-   ##
============================================
+ Coverage     96.24%   96.25%   +0.01%     
============================================
  Files           108      107       -1     
  Lines         23419    23568     +149     
============================================
+ Hits          22539    22686     +147     
- Misses          880      882       +2
Flag Coverage Δ
#doctesting 31.78% <28.29%> (ø) ⬆️
#nobyte 93.53% <96.08%> (+0.01%) ⬆️
#numpy 31.31% <22.18%> (-0.06%) ⬇️
#pexpect 53.6% <51.39%> (+0.05%) ⬆️
#pluggymaster 95.1% <98.21%> (+0.04%) ⬆️
#py27 94.63% <98.21%> (+0.02%) ⬆️
#py34 93.92% <96.42%> (+0.04%) ⬆️
#py35 93.93% <96.42%> (+0.04%) ⬆️
#py36 94.85% <96.42%> (+0.02%) ⬆️
#py37 94.09% <96.42%> (+0.04%) ⬆️
#trial 33.95% <22.18%> (-0.08%) ⬇️
#xdist 94.67% <97.91%> (+0.02%) ⬆️
Impacted Files Coverage Δ
testing/test_warnings.py 99.15% <100%> (+0.71%) ⬆️
testing/test_terminal.py 99.4% <100%> (ø) ⬆️
src/_pytest/warning_types.py 100% <100%> (ø)
src/_pytest/deprecated.py 100% <100%> (ø) ⬆️
testing/test_resultlog.py 100% <100%> (ø) ⬆️
testing/test_capture.py 99.24% <100%> (-0.01%) ⬇️
src/_pytest/pytester.py 89.05% <100%> (-0.02%) ⬇️
src/_pytest/fixtures.py 98.49% <100%> (ø) ⬆️
testing/test_junitxml.py 98.57% <100%> (ø) ⬆️
testing/python/metafunc.py 95.74% <100%> (-0.09%) ⬇️
... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 29bfa5e...f63c683. Read the comment docs.

@coveralls
Copy link

coveralls commented Sep 5, 2018

Coverage Status

Coverage increased (+0.05%) to 94.088% when pulling f63c683 on nicoddemus:internal-warnings into 29bfa5e on pytest-dev:features.

@RonnyPfannschmidt
Copy link
Member

@nicoddemus @blueyed it seems quite painful that the baseline now takes more time that a full test originally

@nicoddemus nicoddemus merged commit 531b76a into pytest-dev:features Sep 5, 2018
@nicoddemus nicoddemus deleted the internal-warnings branch September 5, 2018 17:05
@blueyed
Copy link
Contributor

blueyed commented Sep 5, 2018

@RonnyPfannschmidt

it seems quite painful that the baseline now takes more time that a full test originally

?
Do you mean the 4 test jobs are slower than the full build?
Please provide a reference then (URL, Travis/AV?).. the full build was ~2h before, so I do not think that's the case really.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants